Repository navigation
ci: skip the milestone check in forks instead of failing it - #8053
PastaPastaPasta merged 1 commit into
Conversation
Milestones only mean something on dashpay/dash. In forks, pull requests (for example stacked PRs opened against a contributor's own fork) failed "Require a milestone" even though there is nothing to set. Gate the job on the repository so it is skipped there instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
No actionable comments were generated in the recent review. WalkthroughThe milestone workflow job now runs only when the repository is Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
Merge Risk:
|
|
🕓 Review not started yet because the new head is waiting for the 30-minute push debounce.
Commit eac03d5. Normal review starts when eligible; priority review starts as soon as a slot is available. |
Issue being fixed or feature implemented
"Check PR milestone / Require a milestone" also runs in forks of this repo, where it fails on every non-draft pull request (for example stacked PRs opened against a contributor's own fork). Milestones only mean something on dashpay/dash, so in a fork the check is a red X that nobody can or should clear.
What was done?
Gate the job on
github.repository == 'dashpay/dash', the same guardpredict-conflicts.ymland the Guix release job already use. In forks the job is now skipped rather than failed; on dashpay/dash nothing changes.How Has This Been Tested?
Parsed the workflow and checked the job condition. The check runs on
pull_request_target, which uses the base branch's workflow, so the new condition takes effect on PRs only after this merges.Breaking Changes
None.
Checklist:
🤖 Generated with Claude Code